Associated type bounds: clarify stuff...#4
Conversation
…hings unresolved.
| ## Notes on the meaning of `impl Trait<Assoc: Bound>` | ||
|
|
||
| Note that in the context `-> impl Trait<Assoc: Bound>`, since the | ||
| `Trait` is existentially quantified, so is in effect also the `Assoc`. |
There was a problem hiding this comment.
This could use a bit of grammar cleanup for clarity. How about: since the Trait is existentially quantified, the Assoc is as well.
| fn printables() -> impl Iterator<Item = impl Display> { .. } | ||
| ``` | ||
|
|
||
| For `arg: impl Trait<Assoc: Bound>`, it can likewise be seen as: |
|
|
||
| Note that in the context `-> impl Trait<Assoc: Bound>`, since the | ||
| `Trait` is existentially quantified, so is in effect also the `Assoc`. | ||
| Semantically speaking, `fn printables..` is equivalent to: |
| For `arg: impl Trait<Assoc: Bound>`, it can likewise be seen as: | ||
| `arg: impl Trait<Assoc = impl Bound>`. | ||
|
|
||
| ## Meaning of `existential type Foo: Trait<Assoc: Bound>` |
There was a problem hiding this comment.
Please include notes in this section that 1) reference the existential type RFC by number and 2) explicitly state that "like that RFC, this documentation uses the non-final syntax for existential type aliases".
There was a problem hiding this comment.
Also, please edit the tracking issue for that RFC to request that when the syntax gets finalized, this RFC should be updated.
|
I was thinking about my original read of this specifying bounds on existential types again fn foo() -> impl Iterator<Item: Display> { ... }existential type _0 where _0: Iterator, <_0 as Iterator>::Item: Display;
fn foo() -> _0 { ... }This actually makes a lot of sense to me after reconsidering it, extending existential types to be able to carry multiple bounds should be a pretty straightforward extension to their capabilities. Likely the reason it hasn't been mentioned before is that it's unrequired for the main goal of adding a base syntax to represent What I'm unsure about is if this differs in any way from the proposed desugaring. For generic parameters there is a difference because adding a new anonymous generic type parameter inhibits turbo-fish, but it seems that existential type declarations don't suffer the same problem. If it wasn't for the turbo-fish issue it seems that specifying the desugaring as |
I agree; in any case, the compiler is free to implement this logic internally even if it is not exposed as surface syntax.
So I think the proposed desugaring is still via I don't think there is any observable difference from the user's perspective.
Agreed. |
|
Merging then :) |
Document more Community Team goals
3 participants
See changes ;)